Modifying TCP’s Congestion Control for High Speeds

We are working on a modification to TCP’s window increase/decrease algorithm that would allow TCP to run with high congestion windows with realistic packet drop rates. TCP’s sending rate is roughly 1:2=pp packets per round-trip time, for p the packet loss rate on the path. This is a direct consequence of TCP’s halving its congestion window in response to loss, and increasing the congestion window by one packet per round-trip time otherwise. TCP’s response function, with its average congestion window of W = p1:5=pp packets, places an upper bound on achievable congestion windows, given some underlying packet drop rate p1 from corruption and/or congestion. For example, if the packet corruption rate p1 is 10 2k, this limits the average congestion window to p1:5 10k. (Note that, for 1500-byte packets, a packet corruption rate of 10 2k results from a bit corruption rate of 1:5 10 2k 3) For example, for a TCP connection with 1500-byte packets and a 100 ms round-trip time, filling a 10 Gbps pipe would require a congestion window of W = 83; 333 packets, and a packet drop rate of at most one drop every N = 5; 000; 000; 000 packets (because N = W 2=1:5). This is at most one drop per S = 6000 seconds (because S = N=(10W ) = W=15). This is past the limits of achieveable fiber error rates. In contrast, to fill a 100Mb pipe, the loss rate must not exceed 1 in 500,000 packets, or equivalently, one per S = 60 seconds (because S = N=(10W ) = W=15). It is easy to design congestion control schemes that achieve higher sending rates at a given loss rate. However, the challenge is to do so while retaining the TCP-compatibility (or TCP-friendliness) properties of the congestion control algorithm; any new congestion control algorithm will have to coexist with existing TCP implementations, and the challenge is to enable the modified congestion control algorithms to achieve high speed while, at the same time, not unfairly stealing bandwidth from unmodified TCPs. Some might argue that fairness does not matter, and that future networks will use QoS mechanisms and per-flow scheduling (or other forms of router-enforced fairness). In contrast, we expect that, while QoS mechanisms and a range of scheduling mechanisms will likely have an important place in future networks, best-effort traffic and FIFO scheduling will continue to have their place also, due to their fundamental simplicity and “good enough” performance.